1. Technical Field of the Invention
This invention relates to computer programming. More particularly, it relates to creation of dynamic web applications using the Java programming language.
2. Background Art
The art is familiar with ways to create a web application whose pages are extremely dynamic or numerous. Dynamic web pages are not new. For years people wrote adequate web applications by using the “Common Gateway Interface” (CGI) from C programs. More recently, many programmers use the Java programming language and the Java Servlet technology to create a dynamic web page. A related technology that allows for a better separation between code and presentation is the Java Server Pages technology.
A Java Server page is a textual document that describes how to create a response object from a request object for a given protocol. These are described in “JavaServer Pages™ Specification”, Version 2.0, Chapter JSP.1. Sun Microsystems, Copyright 2003.
Heretofore, to write a dynamic web page to display the time of day, for example, a servlet program would be coded something like the following simplified example:
import java.io.*;import java.util.Date;import javax.servlet.*;import javax.servlet.http.*;public class DateServlet extends HttpServlet { public void doGet(HttpServletRequest req,      HttpServletResponse resp) {  PrintWriter out = resp.getWriter( );  out.write(“<html><body>The time is ”);  out.write(new Date( ).toString( ));  out.write(“</body></html>”); }}
For a simple web page, this suffices, but not for a more complicated web page, where the services of someone skilled in composing HTML and who also knows Java programming would be required.
The evolution of the servlet technology that makes it easier for non-programmers to create pages is the Java Server Pages (JSP) technology. The dynamic page above can be expressed as a JSP in the following way:
<html><body>The time is <%= new Date( ).toString( ) %></body></html>
This syntax is far more convenient for someone skilled in HTML composition, but not in programming. It is just a different way to express the servlet syntax, however. It's important to realize that at runtime, this will get converted into a servlet as well by the JSP container. That is, when this JSP page is first requested by a browser, the JSP container will read the file shown above and produce servlet source code roughly equivalent to the servlet example shown originally. It will then invoke the Java compiler to convert that Java source code into Java object code. Then the new servlet will be loaded and invoked to process the request, much as if the dynamic page had originally been expressed in the servlet form.
The JSP example shown above seems easier to write, but suppose the amount of Java code was more extensive than in the example. For example, to show a lunch menu it may be necessary to write code to look up information in a database and format it in a table. In such a case, the JSP file becomes a hard-to-read mix of markup and Java code. A better approach would allow the user-interface experts to focus on the HTML markup, while Java programmers can concentrate on the programming logic, without either party having to worry about interfering with the part of the file owned by the other. To address this requirement, the concept of custom tags, and custom tag libraries that provide implementations of those tags, has been introduced. [See “JavaServer Pages™ Specification”, Version 2.0, Chapter JSP.8. Sun Microsystems, Santa Clara, Calif. Copyright 2003.] Using such tags, to show a lunch menu, the page composer might create JSP markup like the following:
<html><body><p>Today's lunch menu is the following:</p><caf:lunchMenu view=”standard”/><p>Vegetarians may choose from the following meat-freealternatives:</p><caf:lunchMenu view=”vegetarian”/></body></html>
In this example, the page composer uses “custom tags” to insert dynamic information. The programmer provides a Java library that implements these custom tags. Just as in the last JSP example, when this page is first requested by a browser, the JSP container reads in the JSP file and creates Java source code, which it then compiles into Java object code. Where the JSP refers to a custom tag, the produced Java code will make a call to a library routine provided by the programmer. In this way, the programmer and the user-interface expert can each focus on their specialties.
The JSP example that uses custom tags is sufficient for many web applications, but fails to adequately address the following.
1. Web Applications that have Many Thousands of Dynamic Pages.
As stated above, a JSP file must be compiled into a servlet before it can be accessed. In order to do this, the JSP container creates Java code to represent the servlet. It invents a Java class name to use for this Java code, compiles the source code into object code, loads the resulting Java class definition into memory, and proceeds to use the loaded code. There is quite a bit of memory overhead in this operation. There is certain class-definition information that accompanies every new Java class that puts a strain on memory resources. If a JSP page is referenced once in the lifetime of the web application, the class definition for that class will get loaded and remain in memory until the web application ends. This can be a problem if the web application is large enough. It stands to reason that many future web applications will large enough to encounter this problem.
2. Web Applications Whose JSP Pages are not Static.
In some environments, it is convenient to represent pages as JSP files, yet still give the programmer the ability to fine-tune the contents of the web page before it is displayed. For example, a certain task of the web application might desire to add or remove markup from the JSP using Java code before the page is shown. The straightforward approach to implementing this would be to write a new JSP file each time the task wishes to make an alteration to the page, but this approach would cause a new servlet class to be created and loaded for each variation of the JSP file, quickly using up memory.
3. Web Applications Whose Pages are not Stored as JSP Markup.
In order to provide support for “pervasive” devices such as cell phones and PDAs, many dynamic web pages are represented on the server in some sort of abstract XML. When a page is referenced, the XML is converted at runtime to the markup that is appropriate for the target device. It would be useful and convenient if existing custom tag libraries could be used by the conversion code. To do so, the conversion code would dynamically create JSP markup when the page is referenced. But if a traditional JSP container is used to process the JSP markup to convert it to the final form (HTML or some other markup language), a new servlet class will be created and loaded into memory. But again, this is impractical, as it would quickly consume memory resources. Also, the latency involved with generating and compiling the Java code is usually unacceptable.